home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-x400ops-mgtdomains-ops-06.txt < prev    next >
Encoding:
Text File  |  1993-10-15  |  27.4 KB  |  918 lines
  1.  
  2.  
  3.    Operational Requirements for X.400 Management Domains
  4.  
  5.                   in the GO-MHS Community
  6.  
  7.                       October 15, 1993
  8.  
  9.                       Robert A. Hagens
  10.                        hagens@ans.net
  11.        DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US
  12.  
  13.                          Alf Hansen
  14.                    Alf.Hansen@uninett.no
  15.         G=Alf; S=Hansen; O=uninett; P=uninett; C=no
  16.                    Alf.Hansen@uninett.no
  17.  
  18.                      $ Revision: 1.18 $
  19.  
  20.          <draft-ietf-x400ops-mgtdomains-ops-06.txt>
  21.  
  22.  
  23.                     Status of this Memo
  24.  
  25.  
  26. This  document  specifies  a  set  of  minimal   operational
  27. requirements  that  shall  be  implemented by all Management
  28. Domains (MDs) in the Global  Open  MHS  Community  (GO-MHS).
  29. This  document defines the core operational requirements; in
  30. some cases, technical detail  is  handled  by  reference  to
  31. other documents.
  32.  
  33. The GO-MHS Community is defined as all  organizations  which
  34. meet the requirements described in this document.
  35.  
  36. This document is an  Internet  Draft.  Internet  Drafts  are
  37. working  documents  of  the  Internet Engineering Task Force
  38. (IETF), its Areas, and its Working Groups. Note  that  other
  39. groups  may  also  distribute  working documents as Internet
  40. Drafts.
  41.  
  42. Internet Drafts are draft documents valid for a  maximum  of
  43. six  months.  Internet  Drafts  may be updated, replaced, or
  44. obsoleted by  other  documents  at  any  time.   It  is  not
  45. appropriate  to use Internet Drafts as reference material or
  46. to cite them other than as a "working  draft"  or  "work  in
  47. progress."
  48.  
  49. Please check the I-D  abstract  listing  contained  in  each
  50. Internet Draft directory to learn the current status of this
  51. or any other Internet Draft.
  52.  
  53. When agreement is reached, it will be submitted to  the  RFC
  54. editor as an experimental RFC.  Distribution of this memo is
  55. unlimited. Please send comments to the  authors  or  to  the
  56.  
  57.  
  58. INTERNET-DRAFT            [Page 1]       Exp. Date: 04/15/94
  59.  
  60. discussion group:
  61.  
  62.                 ietf-osi-x400ops@cs.wisc.edu
  63.   S=ietf-osi-x400ops; OU1=cs; O=UW-Madison; P=xnren; C=us
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. INTERNET-DRAFT            [Page 2]       Exp. Date: 04/15/94
  116.  
  117. 1.  Introduction
  118.  
  119. There  are  several  large,   operational   X.400   services
  120. currently  deployed. Many of the organizations in these ser-
  121. vices are connected to  the  Internet.  A  number  of  other
  122. Internet-connected  organizations  are  beginning to operate
  123. internal X.400 services (for example, U.S. government organ-
  124. izations  following  U.S.  GOSIP).  The  motivation for this
  125. document is to foster  a  GO-MHS  Community  that  has  full
  126. interoperability  with  the existing E-mail service based on
  127. RFC-822.
  128.  
  129. The goal of this document is to  unite  regionally  operated
  130. X.400  services  on  the  various continents into one GO-MHS
  131. Community (as seen from an end-user's point of view).  Exam-
  132. ples of such regional services are the COSINE MHS Service in
  133. Europe and the XNREN service in the U.S.
  134.  
  135. A successful GO-MHS Community is dependent on  decisions  at
  136. both  the  national  and international level. National X.400
  137. service providers are responsible for the implementation  of
  138. the  minimum requirements defined in this document. In addi-
  139. tion to these minimum  requirements,  national  requirements
  140. may be defined by each national service provider.
  141.  
  142. This document refers to other documents which are  published
  143. as RFCs. These documents are [1], [2], [3], [4], [6] and [7]
  144. in the reference list.[1]
  145.  
  146. This document handles issues concerning X.400 1984 and X.400
  147. 1988  to 1984 downgrading. Issues concerning pure X.400 1988
  148. are left for further study.
  149.  
  150. We are grateful to Allan Cargille and Lawrence Landweber for
  151. their input and guidance on this paper. This paper is also a
  152. product of discussions in the IETF X.400 Operations  WG  and
  153. the RARE WG-MSG (former RARE WG1 (on MHS)).
  154.  
  155.  
  156. 1.1.  Terminology
  157.  
  158. This document defines requirements, recommendations and con-
  159. ventions.   Throughout  the  document, the following defini-
  160. tions apply: a requirement is specified with the word shall.
  161. A  recommendation is specified with the word should.  A con-
  162. vention is specified with the word might.   Conventions  are
  163. intended  to make life easier for RFC-822 systems that don't
  164.  
  165.    [1] Note: Reference [4] will be submitted to the IESG  as
  166. Proposed Standard together with the submission of this docu-
  167. ment.
  168.  
  169.  
  170.  
  171.  
  172. INTERNET-DRAFT            [Page 3]       Exp. Date: 04/15/94
  173.  
  174. follow the host requirements.
  175.  
  176.  
  177. 1.2.  Profiles
  178.  
  179. Different communities have different  profile  requirements.
  180. The following is a list of such profiles.
  181.  
  182.     o U.S. GOSIP - unspecified version
  183.     o ENV - 41201
  184.     o UK GOSIP for X.400(88)
  185.  
  186. In the case when mail traffic is going from the RFC-822 mail
  187. service  to  the  GO-MHS  Community, the automatic return of
  188. contents when mail is non-delivered should be  requested  by
  189. RFC  1327  gateways  and should be supported at the MTA that
  190. generates the non-delivery report.  However,  it  should  be
  191. noted  that this practice maximizes the cost associated with
  192. delivery reports.
  193.  
  194.  
  195. 2.  Architecture of the GO-MHS Community
  196.  
  197. In order to facilitate a coherent deployment of X.400 in the
  198. GO-MHS  Community  it  is  necessary  to  define, in general
  199. terms, the overall structure and organization of  the  X.400
  200. service.   This  section  is broken into several parts which
  201. discuss management domains, lower layer connectivity issues,
  202. and overall routing issues.
  203.  
  204. The GO-MHS Community will operate as a single MHS community,
  205. as defined in reference [1].
  206.  
  207.  
  208. 2.1.  Management Domains
  209.  
  210. The X.400 model supports  connectivity  between  communities
  211. with different service requirements; the architectural vehi-
  212. cle for this is a Management Domain. Management domains  are
  213. needed   when   different   administrations  have  different
  214. specific requirements.  Two types of management domains  are
  215. defined  by  the  X.400  model: an Administration Management
  216. Domain (ADMD) and a Private Management Domain (PRMD).
  217.  
  218. Throughout the world in various  countries  there  are  dif-
  219. ferent  organizational policies for MDs.  All of these poli-
  220. cies are legal according to the X.400  standard.  Currently,
  221. X.400  service providers in a country (inside or outside the
  222. GO-MHS Community), are organized as:
  223.  
  224.     a) One or several ADMDs.
  225.     b) One or several PRMDs and with no ADMDs present in
  226.        the country, or that are not connected to any ADMD.
  227.  
  228.  
  229. INTERNET-DRAFT            [Page 4]       Exp. Date: 04/15/94
  230.  
  231.     c) One or several PRMDs connected to one or several ADMDs.
  232.  
  233.  
  234. Or in combinations of a), b) and c).  At this  stage  it  is
  235. not  possible  to  say  which  model  is the most effective.
  236. Thus, the GO-MHS Community shall allow every model.
  237.  
  238.  
  239. 2.2.  The RELAY-MTA
  240.  
  241. The X.400 message routing decision process  takes  as  input
  242. the  destination O/R address and produces as output the name
  243. (and perhaps connection information) of  the  MTA  who  will
  244. take  responsibility  of delivering the message to the reci-
  245. pient. The X.400 store and forward model permits  a  message
  246. to  pass  through  multiple  MTAs.  However, it is generally
  247. accepted that the most efficient path for a message to  take
  248. is one where a direct connection is made from the originator
  249. to the recipient's MTA.
  250.  
  251. Large scale deployment of X.400 in the GO-MHS Community will
  252. require  a well deployed directory infrastructure to support
  253. routing. In the GO-MHS Community X.500 is considered  to  be
  254. the  best  protocol  for  such  an  infrastructure.  In this
  255. environment, a routing decision can be made by searching the
  256. directory  with a destination O/R address in order to obtain
  257. the name of the next hop MTA. This  MTA  may  be  a  central
  258. entry  point  into  an  MD, or it may be the destination MTA
  259. within an MD.
  260.  
  261. Deployment  of  X.400  without  a  well  deployed  Directory
  262. infrastructure,  will  require  the  use of static tables to
  263. store  routing  information.  These  tables  (keyed  on  O/R
  264. addresses), will be used to map a destination O/R address to
  265. a next hop MTA.  In order to facilitate  efficient  routing,
  266. one  could  build  a  table  that contains information about
  267. every MTA in every MD.  However, this table would  be  enor-
  268. mous  and very dynamic, so this is not feasible in practice.
  269. Therefore, it is necessary to use the concept  of  a  RELAY-
  270. MTA.
  271.  
  272. The purpose of a RELAY-MTA is to  act  as  a  default  entry
  273. point into an MD. The MTA that acts as a RELAY MTA for an MD
  274. shall be capable of accepting responsibility  for  all  mes-
  275. sages  that  it  receives that are destined for well-defined
  276. recipients in that MD.
  277.  
  278. The use of a RELAY-MTA for routing is defined  by  reference
  279. [1].  RELAY-MTAs in the GO-MHS Community shall route accord-
  280. ing to reference [1].
  281.  
  282.  
  283.  
  284.  
  285.  
  286. INTERNET-DRAFT            [Page 5]       Exp. Date: 04/15/94
  287.  
  288. 2.3.  Lower Layer Stack Incompatibilities
  289.  
  290. A requirement for successful operation of the GO-MHS Commun-
  291. ity is that all users can exchange messages. The GO-MHS Com-
  292. munity is not dependent  on  the  traditional  TCP/IP  lower
  293. layer  protocol  suite.  A variety of lower layer suites are
  294. used as carriers of X.400 messages.
  295.  
  296. For example, consider Figure 1.
  297.  
  298.   -----------------------------------------------------
  299.   !                                                   !
  300.   !            PRMD A                                 !
  301.   !        --------------------                       !
  302.   !        !   o       x      !                       !
  303.   !        !                  !                       !
  304.   !        !     o        w   !                       !
  305.   !        !          z       !                       !
  306.   !        --------------------                       !
  307.   !                                PRMD B             !
  308.   !                            ------------------     !
  309.   !                            !      o     o   !     !
  310.   !    PRMD C                  !  o             !     !
  311.   !  ------------------        !      o     z   !     !
  312.   !  !       o        !        !                !     !
  313.   !  !  o        x    !        ------------------     !
  314.   !  !     o        w !                               !
  315.   !  !        o       !                               !
  316.   !  ------------------                               !
  317.   !                                                   !
  318.   !               Key: Each character the in          !
  319.   !                    the boxes illustrates an MTA.  !
  320.   !                                                   !
  321.   !                    x: TP0/RFC1006/TCP RELAY-MTA   !
  322.   !                    w: TP4/CLNP RELAY-MTA          !
  323.   !                    z: TP0/CONS/X.25 RELAY-MTA     !
  324.   !                    o: MTA                         !
  325.   -----------------------------------------------------
  326.  
  327.               Figure 1: A Deployment Scenario
  328.  
  329.  
  330. PRMD A has three RELAY-MTAs which collectively provide  sup-
  331. port   for  the  TP0/CONS/X.25,  TP0/RFC1006,  and  TP4/CLNS
  332. stacks.[2] Thus, PRMD A is reachable via these stacks.  How-
  333. ever, since PRMD B only supports the TP0/CONS/X.25 stack, it
  334. is not reachable from  the  TP0/RFC  1006  or  the  TP4/CLNS
  335.  
  336.  
  337.    [2] Note: it is acceptable for a single RELAY-MTA to sup-
  338. port  more  than  one  stack.  Three RELAY-MTAs are shown in
  339. this figure for clarity.
  340.  
  341.  
  342.  
  343.  
  344. INTERNET-DRAFT            [Page 6]       Exp. Date: 04/15/94
  345.  
  346. stack. PRMD C supports TP0/RFC1006 and TP4/CLNS. Since  PRMD
  347. B  and  PRMD C do not share a common stack, how is a message
  348. from PRMD C to reach a recipient in PRMD B?
  349.  
  350. One solution to this problem  is  to  require  that  PRMD  B
  351. implement  a  stack  in common with PRMD C. However this may
  352. not be a politically acceptable answer to PRMD B.
  353.  
  354. Another solution is to implement a transport service  bridge
  355. (TSB)  between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B.
  356. This will solve the problem for PRMD C and B.  However,  the
  357. lack  of coordinated deployment of TSB technology makes this
  358. answer alone unacceptable on an international scale.
  359.  
  360. The solution to this problem  is  to  define  a  coordinated
  361. mechanism  that allows PRMD B to advertise to the world that
  362. it has made a bilateral agreement with  PRMD  A  to  support
  363. reachability to PRMD B from the TP0/RFC 1006 stack.
  364.  
  365. This solution does not require that every MTA or MD directly
  366. support  all  stacks. However, it is a requirement that if a
  367. particular stack is not directly supported by an MD, the  MD
  368. will  need  to make bilateral agreements with other MD(s) in
  369. order to assure that connectivity from that stack is  avail-
  370. able.
  371.  
  372. Thus, in the case of Figure 1, PRMD B can make  a  bilateral
  373. agreement  with  PRMD  A  which provides for PRMD A to relay
  374. messages which arrive on either the TP4/CLNP  stack  or  the
  375. TP0/RFC 1006 stack to PRMD B using the TP0/CONS stack.
  376.  
  377. The policies described in reference [1] define this  general
  378. purpose  solution.  It  is a requirement that all MDs follow
  379. the rules and policies defined by reference [1].
  380.  
  381.  
  382.  
  383. 3.  Description of GO-MHS Community Policies
  384.  
  385. A GO-MD is a Management Domain in the GO-MHS Community.
  386.  
  387. The policies described in this section constitute a  minimum
  388. set  of  common  policies  for GO-MDs. They are specified to
  389. ensure interoperability between
  390.  
  391.     - all GO-MDs.
  392.     - all GO-MDs and the RFC-822 mail service (SMTP).
  393.     - all GO-MDs and other X.400 service providers.
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401. INTERNET-DRAFT            [Page 7]       Exp. Date: 04/15/94
  402.  
  403. 3.1.  X.400 Address Registration
  404.  
  405. An O/R address is a descriptive name for a UA that has  cer-
  406. tain  characteristics  that  help  the  Service Providers to
  407. locate the UA. Every O/R address is an  O/R  name,  but  not
  408. every  O/R  name  is  an  O/R  address. This is explained in
  409. reference [5], chapter 3.1.
  410.  
  411. Uniqueness of X.400 addresses shall be used to  ensure  end-
  412. user connectivity.
  413.  
  414. Mailboxes shall be addressed according to the description of
  415. O/R  names,  Form  1,  Variant 1 (see reference [5], chapter
  416. 3.3.2). The attributes shall be regarded as a hierarchy of
  417.  
  418.     Country name (C)
  419.     Administration domain name (ADMD)
  420.     [Private domain name] (PRMD)
  421.     [Organization name] (O)
  422.     [Organizational Unit Names] (OUs)
  423.     [Personal name] (PN)
  424.     [Domain-defined attributes] (DDAs)
  425.  
  426. Attributes enclosed in  square  brackets  are  optional.  At
  427. least one of PRMD, O, OU and PN names shall be present in an
  428. O/R address. At least one of PN and DDA shall be present.
  429.  
  430. In general a subordinate address  element  shall  be  unique
  431. within  the  scope  of  its immediately superior element. An
  432. exception is PRMD, see  section  3.1.3.  There  shall  exist
  433. registration authorities for each level, or mechanisms shall
  434. be available to ensure such uniqueness.
  435.  
  436.  
  437. 3.1.1.  Country (C)
  438.  
  439. The values of the  top  level  element,  Country,  shall  be
  440. defined  by  the set of two letter country codes, or numeric
  441. country codes in ISO 3166.
  442.  
  443.  
  444. 3.1.2.  Administration Management Domain (ADMD)
  445.  
  446. The values of the ADMD  field  are  decided  on  a  national
  447. basis.  Every  national decision made within the GO-MHS com-
  448. munity shall be supported by a GO-MD.
  449.  
  450.  
  451. 3.1.3.  Private Management Domain (PRMD)
  452.  
  453. The PRMD values should be unique within a country.
  454.  
  455.  
  456.  
  457.  
  458. INTERNET-DRAFT            [Page 8]       Exp. Date: 04/15/94
  459.  
  460. 3.1.4.  Organization (O)
  461.  
  462. Organization values shall be unique within  the  context  of
  463. the subscribed PRMD or ADMD if there is no PRMD. For clarif-
  464. ication: The following situation is legal:
  465.  
  466.     1) C=FI; ADMD=FUMAIL; O=FUNET.
  467.     2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET.
  468.  
  469. In this case 1) and 2) are different addreses. (Note that 2)
  470. at  this point is a hypotethical address). O=FUNET is a sub-
  471. scriber both at ADMD=FUMAIL, 1), and at PRMD=NOKIA, 2).
  472.  
  473.  
  474. 3.1.5.  Organizational Units (OUs)
  475.  
  476. If used, a unique hierarchy of OUs shall be implemented. The
  477. top  level  OU is unique within the scope of the immediately
  478. superior address element (i.e., Organization, PRMD or ADMD).
  479. Use of multiple OUs may be confusing.
  480.  
  481.  
  482. 3.1.6.  Given Name, Initials, Surname (G I S)
  483.  
  484. Each Organization can define its own Given-names,  Initials,
  485. and  Surnames  to  be  used  within the Organization. In the
  486. cases when Surnames are not unique within an O  or  OU,  the
  487. Given-name  and/or  Initial  shall  be  used to identify the
  488. Originator/Recipient. In the rare cases when more  than  one
  489. user  would  have  the same combination of G, I, S under the
  490. same O and/or OUs, each organization is free to find a prac-
  491. tical  solution,  and  provide  the  users  with  unique O/R
  492. addresses.
  493.  
  494. Either one of Given-name or Initials  should  be  used,  not
  495. both.  Periods shall not be used in Initials.
  496.  
  497. To avoid problems with the mapping of the X.400 addresses to
  498. RFC-822  addresses, the following rules might be used. ADMD,
  499. PRMD, O, and OU values should consist  of  characters  drawn
  500. from  the alphabet (A-Z), digits (0-9), and minus.  Blank or
  501. Space characters should be avoided.  No distinction is  made
  502. between  upper  and lower case. The last character shall not
  503. be a minus sign or period.  The first  character  should  be
  504. either a letter or a digit (see reference [6] and [7]).
  505.  
  506.  
  507. 3.1.7.  Domain Defined Attributes (DDAs)
  508.  
  509. The GO-MHS Community shall allow the use of  domain  defined
  510. attributes. Note: Support for DDAs is mandatory in the func-
  511. tional profiles, and all software must  upgrade  to  support
  512. DDAs.  The following DDAs shall be supported by a GO-MD:
  513.  
  514.  
  515. INTERNET-DRAFT            [Page 9]       Exp. Date: 04/15/94
  516.  
  517.     "RFC-822" - defined in reference [3].
  518.  
  519.  
  520. The following DDAs should be supported by a GO-MD:
  521.  
  522.     "COMMON" - defined in reference [2].
  523.  
  524.  
  525.  
  526. 3.2.  X.400 88 -> 84 Downgrading
  527.  
  528. The requirements in reference [2] should be  implemented  in
  529. GO-MDs
  530.  
  531.  
  532. 3.3.  X.400 / RFC-822 address mapping
  533.  
  534. All GO-MHS Community end-users shall be reachable  from  all
  535. end-users  in  the  RFC-822  mail  service  in  the Internet
  536. (SMTP), and vice versa.
  537.  
  538. The address mapping issue is split into two parts:
  539.  
  540.     1) Specification of RFC-822 addresses seen from the X.400 world.
  541.     2) Specification of X.400 addresses seen from the RFC-822 world.
  542.  
  543. The mapping of X.400 and RFC-822  addresses  shall  be  per-
  544. formed according to reference [3].
  545.  
  546.  
  547. 3.3.1.  Specification of RFC-822  Addresses  seen  from  the
  548. X.400 World
  549.  
  550. Two scenarios are described:
  551.  
  552.     A. The RFC-822 end-user belongs to an organization with no defined X.400
  553.        standard attribute address space.
  554.     B. The RFC-822 end-user belongs to an organization with a defined X.400
  555.        standard attribute address space.
  556.  
  557.  
  558. Organizations belong to scenario B if their X.400  addresses
  559. are registered according to the requirements in section 3.1.
  560.  
  561.  
  562. 3.3.1.1.  An  Organization  with  a  defined  X.400  Address
  563. Space
  564.  
  565. An RFC-822 address for an  RFC-822  mail  user  in  such  an
  566. organization  shall be in the same address space as a normal
  567. X.400 address for X.400  users  in  the  same  organization.
  568. RFC-822  addresses  and X.400 addresses are thus sharing the
  569. same address space. Example:
  570.  
  571.  
  572. INTERNET-DRAFT           [Page 10]       Exp. Date: 04/15/94
  573.  
  574. University of Wisconsin-Madison is  registered  under  C=US;
  575. ADMD=Internet;  PRMD=XNREN;  with  O=UW-Madison and they are
  576. using OU=cs to address end-users in the  CS-department.  The
  577. RFC-822  address  for RFC-822 mail users in the same depart-
  578. ment is: user@cs.wisc.edu.
  579.  
  580. An X.400 user in the GO-MHS Community will address the  RFC-
  581. 822 mail user at the CS-department with the X.400 address:
  582.  
  583.     C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;
  584.  
  585.  
  586. This is the same address space as is  used  for  X.400  end-
  587. users in the same department.
  588.  
  589.  
  590. 3.3.1.2.  An Organization  with  no  defined  X.400  Address
  591. Space
  592.  
  593. RFC-822 addresses shall  be  expressed  using  X.400  domain
  594. defined  attributes.   The mechanism used to define the RFC-
  595. 822 recipient will vary on a per-country basis.
  596.  
  597. For example, in the U.S., a special PRMD named "Internet" is
  598. defined   to   facilitate   the   specification  of  RFC-822
  599. addresses.  An X.400 user can address an  RFC-822  recipient
  600. in the U.S. by constructing an X.400 address such as:
  601.  
  602.     C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;
  603.  
  604.  
  605. The first part of this address:
  606.  
  607.     C=us; ADMD=Internet; PRMD=Internet;
  608.  
  609.  
  610. denotes the U.S. portion of the Internet community and not a
  611. specific "gateway". The 2nd part:
  612.  
  613.     DD.RFC-822=user(a)some.place.edu
  614.  
  615.  
  616. is the RFC-822 address of the RFC-822 mail user  after  sub-
  617. stitution of non-printable characters according to reference
  618. [3]. The RFC-822  address  is  placed  in  an  X.400  Domain
  619. Defined Attribute of type RFC-822 (DD.RFC-822).
  620.  
  621. Each country is free to choose its own  method  of  defining
  622. the  RFC-822 community.  For example in Italy, an X.400 user
  623. would refer to an RFC-822 user as:
  624.  
  625.     C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it
  626.  
  627.  
  628.  
  629. INTERNET-DRAFT           [Page 11]       Exp. Date: 04/15/94
  630.  
  631. In the UK, an X.400 user would refer to an RFC-822 user as:
  632.  
  633.     C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk
  634.  
  635.  
  636.  
  637. 3.3.2.  Specification of X.400 Addresses seen from the  RFC-
  638. 822 World
  639.  
  640. If an X.400  organization  has  a  defined  RFC-822  address
  641. space,  RFC-822  users  will  be able to address X.400 reci-
  642. pients  in  RFC-822/Internet  terms.  This  means  that  the
  643. address  of  the X.400 user, seen from an RFC-822 user, will
  644. generally be of the form:
  645.  
  646.     Firstname.Lastname@some.place.edu
  647.  
  648.  
  649. where the some.place.edu is a registered Internet domain.
  650.  
  651. This implies the necessity of maintaining  and  distributing
  652. address  mapping  tables to all participating RFC-1327 gate-
  653. ways. The  mapping  tables  shall  be  globally  consistent.
  654. Effective mapping table coordination procedures are needed.
  655.  
  656. If an organization does not have a defined  RFC-822  address
  657. space, an escape mapping (defined in reference [3]) shall be
  658. used. In this case, the address of the X.400 user, seen from
  659. an RFC-822 user, will be of the form:
  660.  
  661.     "/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
  662.                                     some.gateway.edu
  663.  
  664.  
  665. Note that reference [7] specifies that quoted left-hand side
  666. addresses  must be supported and that these addresses may be
  667. greater than 80 characters long.
  668.  
  669. This escape mapping shall also be used for  X.400  addresses
  670. which do not map cleanly to RFC-822 addresses.
  671.  
  672. It is recommended that an organization with no defined  RFC-
  673. 822  address  space,  should register RFC-822 domains at the
  674. appropriate registration entity for such registrations. This
  675. will  minimize  the  number  of addresses which must use the
  676. escape mapping.
  677.  
  678. If the escape mapping is not used, RFC-822  users  will  not
  679. see  the  difference between an Internet RFC-822 address and
  680. an address in the GO-MHS Community.  For example:
  681.  
  682. The X.400 address:
  683.  
  684.  
  685.  
  686. INTERNET-DRAFT           [Page 12]       Exp. Date: 04/15/94
  687.  
  688.     C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;
  689.  
  690.  
  691. will from an RFC-822 user look like:
  692.  
  693.     Firstname.Lastname@cpg.cdc.com
  694.  
  695.  
  696.  
  697. 3.4.  Routing Policy
  698.  
  699. To facilitate routing in  the  GO-MHS  Community  before  an
  700. X.500  infrastructure  is  deployed, the following two docu-
  701. ments, a RELAY-MTA  document  and  a  Domain  document,  are
  702. defined.  These  documents are formally defined in reference
  703. [1]. The use of these documents is necessary  to  solve  the
  704. routing  crisis  that  is  present today. However, this is a
  705. temporary solution that will eventually be replaced  by  the
  706. use of X.500.
  707.  
  708. The RELAY-MTA document will define the names  of  RELAY-MTAs
  709. and  their  associated  connection  data  including selector
  710. values, NSAP addresses, supported protocol stacks, and  sup-
  711. ported X.400 protocol version(s).
  712.  
  713. Each entry in the Domain document  consists  of  a  sub-tree
  714. hierarchy  of  an  X.400 address, followed by a list of MTAs
  715. which are willing to accept mail for the address or  provide
  716. a  relay  service  for  it. Each MTA name will be associated
  717. with a priority value. Collectively, the list of  MTA  names
  718. in the Domain document make the given address reachable from
  719. all protocol stacks. In addition, the list of MTAs may  pro-
  720. vide  redundant  paths  to the address, so in this case, the
  721. priority value indicates the preferred  path,  or  the  pre-
  722. ferred order in which alternative routes should be tried.
  723.  
  724. The RELAY-MTA and Domain documents are  coordinated  by  the
  725. group  specified  in the Community document.  The procedures
  726. for document information gathering and distribution, are for
  727. further study.
  728.  
  729.  
  730. 3.5.  Minimum Statistics/Accounting
  731.  
  732. The following are not required for all MTAs. The information
  733. is provided as guidelines for MTA managers.  This is helpful
  734. for observing service use  and  evaluating  service  perfor-
  735. mance.
  736.  
  737. This section defines the data which should be kept  by  each
  738. MTA.  There are no constraints on the encoding used to store
  739. the data (i.e., format).
  740.  
  741.  
  742.  
  743. INTERNET-DRAFT           [Page 13]       Exp. Date: 04/15/94
  744.  
  745. For each  message/report  passing  the  MTA,  the  following
  746. information should be collected.
  747.  
  748. The following fields should be collected.
  749.  
  750.     Date
  751.     Time
  752.     Priority
  753.     Local MTA Name
  754.     Size
  755.  
  756.  
  757. The following fields are conditionally collected.
  758.  
  759.     From MTA Name (fm)
  760.     To MTA Name (tm)
  761.     Delta Time (dt)
  762.     Message-id (id)
  763.  
  764. At least one of 'fm' and 'tm' should be present.  If one  of
  765. 'fm'  and  'tm'  is  not present, 'id' should be present. If
  766. both 'fm' and 'tm' are  present,  then  'dt'  indicates  the
  767. number  of  minutes that the message was delayed in the MTA.
  768. If 'id' cannot be mapped locally because of  log  file  for-
  769. mats,  'id'  is  not  present  and every message creates two
  770. lines: one with 'fm' empty and one with 'tm' empty. In  this
  771. case, 'date' and 'time' in the first line represent the date
  772. and time the message entered the MTA.  In the  second  line,
  773. they represent the date and time the message left the MTA.
  774.  
  775. The following fields are optionally collected.
  776.  
  777.     From Domain (fd)
  778.     To Domain (td)
  779.  
  780. For route tracing, 'fd' and 'td' are useful. They  represent
  781. X.400  OU's,  O,  PRMD, ADMD and C and may be supplied up to
  782. any level of detail.
  783.  
  784.  
  785.  
  786. 4.  Community Document
  787.  
  788. For the GO-MHS community there will exist one single COMMUN-
  789. ITY  document  containing  basic  information  as defined in
  790. reference [1]. First the contact information for the central
  791. coordination  point can be found together with the addresses
  792. for the file server where all the documents are  stored.  It
  793. also  lists  network  names  and  stacks  to  be used in the
  794. RELAY-MTA and DOMAIN documents. The  GO-MHS  community  must
  795. agree  on its own set of mandatory and optional networks and
  796. stacks.
  797.  
  798.  
  799.  
  800. INTERNET-DRAFT           [Page 14]       Exp. Date: 04/15/94
  801.  
  802. 5.  Authors' Addresses
  803.  
  804.  
  805.    Alf Hansen
  806.    UNINETT
  807.    Elgesetergt. 10
  808.    Postbox 6883, Elgeseter
  809.    N-7002 Trondheim
  810.    Norway
  811.  
  812.    Phone: +47 7359 2982
  813.    Fax:   +47 7359 6450
  814.  
  815.    Alf.Hansen@uninett.no
  816.    G=Alf; S=Hansen; O=uninett; P=uninett; C=no
  817.  
  818.    Robert Hagens
  819.    Advanced Network & Services, Inc.
  820.    1875 Campus Commons Drive
  821.    Suite 220
  822.    Reston, VA 22091
  823.    U.S.A.
  824.  
  825.    Phone: +1 703 758 7700
  826.    Fax:   +1 703 758 7717
  827.  
  828.    hagens@ans.net
  829.    DDA.RFC-822=hagens(a)ans.net; P=INTERNET; C=US
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857. INTERNET-DRAFT           [Page 15]       Exp. Date: 04/15/94
  858.  
  859.                          References
  860.  
  861. [1]  U. Eppenberger, Routing  Coordination  for  X.400  MHS-
  862.      Services  Within  a  Multi Protocol / Multi Network En-
  863.      vironment, RFC 1465, May 1993.
  864.  
  865.  
  866.  
  867. [2]  S.E. Hardcastle-Kille: X.400 1988 to 1984  downgrading,
  868.      RFC 1328, May 1992.
  869.  
  870.  
  871.  
  872. [3]  S.E. Hardcastle-Kille: Mapping  between  X.400(1988)  /
  873.      ISO 10021 and RFC 822, RFC 1327, May 1992.
  874.  
  875.  
  876.  
  877. [4]  C. Allan  Cargille,  Postmaster  Convention  for  X.400
  878.      Operations,  IETF  Internet Draft, "draft-ietf-x400ops-
  879.      postmaster-03.txt"
  880.  
  881.  
  882.  
  883. [5]  <ref. CCITT Red Book, X.400>
  884.  
  885.  
  886.  
  887. [6]  K. Harrenstien, et al. DOD Internet Host Table Specifi-
  888.      cation.  RFC 952, October 1985.
  889.  
  890.  
  891.  
  892. [7]  R. Braden. Requirements for Internet Hosts --  Applica-
  893.      tion and Support. RFC 1123, October 1989.
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914. INTERNET-DRAFT           [Page 16]       Exp. Date: 04/15/94
  915.  
  916.  
  917.  
  918.